The first kind of services offered through the Internet have been commonly limited to one-to-one, (customer-to-business, user-to-provider, etc) relationship. In this kind of primary service scenario a Service Provider (hereinafter also referred as SP) can provide one or a plurality of services to a plurality of users. While some of said services can be provided on a (let's say) common general basis and consist, for example, on mere information services available to any user and/or being no subject to any user-based customization or authorization; some others services can be customized according to the served user and be, for example, subject to a previous identification and authorization of said user, which could be needed, for example, when the service or its content is to be adapted according to each particular served user or according to his preferences, and/or when the service to be rendered only for those users who has a service account with the SP (e.g. users who has subscribed to the service with the SP).
In the particular case in which the provision of a service is subject to user identification, the SPs implement mechanisms to carry out user authentication, which, commonly, drives to the storage and management of user credentials (e.g. user identifiers and passwords) on each SP. However, this simplified approach can put some inconvenience on the user side for users having various service accounts with various SPs, since they have to remember their credentials to access to the different services provided by these SPs. A user may try to override this drawback by utilizing the same credentials across all these SPs, which might in some cases be not possible (e.g. because a SP impose, at least, the user identifier, or because the same selected user identifier is already assigned to another user in the same SP). However, in any case, the user is forced to provide his credentials every time he accesses a SP.
Identity federation frameworks have been recently developed to, primarily, fix this problem. In short, an identity federation framework comprises a set of functional entities (SPs and others that shall be later cited) and a set of mechanisms which allow a plurality of SPs to share federated identity information of users between them. In this context the term “identity” of a user (also known as “network identity”) refers to the set of attributes that, for said user, are held in the respective service account(s) said user has across one or various SPs.
The “Liberty Alliance Project” LAP (http://www.projectliberty.org/) is a standardization forum for the standardization of identity federation frameworks. Accordingly, some LAP specific terms, functional procedures and functional entities will be referred across this application to illustrate, by way of examples, the functional operation of a well known standardized identity federation framework which, those skilled in the art, would readily identify with the equivalent terms, functional procedures and functional entities of similar frameworks that also provide identity federation.
A first goal of an identity federation framework was to provide the so-called SSO (“Single Sign-On”, also known as “Simplified Sign-On”). SSO allows the users to securely access different services and applications, which can be accessed through SPs that can be even dispersed across different network or administrative domains, without being authenticated every time. The current principle behind SSO states that, for a given session, users shall be able to authenticate once, and then, shall be given access to all their subscribed services that accept such level of authentication. This principle enables a user to access different services without explicitly authenticating for each particular different service he might request. SSO is accomplished by authenticating a user once, and then, with the mediation of a server entity, commonly known as “Identity Provider” IDP, making the resulting authentication valid for entrance to other SPs.
A further goal of an identity federation framework is to provide a new kind of services based on the federated identity of the users. In short, these new kind of services consider the consumption of resources of the federated identities of users across SPs. The term “resource” is a generic term which may refer indistinctly: to data attributes of a federated identity of a user, including those which have a more static nature (such as his name, employee number, user identifier in a given service or network, etc), as well as those which can be more dynamic nature (e.g. data attributes which depends on some service for said user, such as calendar data, current geographical position, etc); and also to services acting on behalf of a user's federated identity (e.g. services which performs some action for his identity, such as sending a short message, sending an electronic mail, etc). In this scenario, a given SP can offer a given service to a user that, for its completion, might need (e.g. as an optional feature, or as an essential feature) the consumption of a resource of the federated identity of said user (e.g. use his credit card number, check or set data on his web-based calendar, use personal information, etc); wherein said resource can be stored and primarily handled in another SP. Said “consumption” can comprise, not only the retrieval and/or updating of said resources, but also the performance of some action on the benefit of an identity (e.g. an attribute of an identity of a user in a SP comprises his mobile phone number, being the action to send a Short Message to this number from this SP). Accordingly a new kind of services can be offered to a user from a SP that, for their accomplishment/customization/etc, can go beyond the mere usage of the own data said SP locally hold for said user.
The provision of this new kind of services is commonly achieved with the intervention of a server entity that provides what is usually known as “discovery service” DS that allows a first SP to access to a second SP which holds the wanted resource. Across the present application the term “Discovery Service server” (or DS server) shall be used to refer to a server entity which provides a Discovery Service DS, regardless of whether said server entity resides in a server machine that further provides or not any other kind of service.
In the terminology commonly used in identity federation frameworks, the aforementioned second SP would act as a WSP (Web Service Provider), and the aforementioned first SP would act as a WSC (Web Service Consumer); whilst the service that allows a WSC to access to an WSP to act upon some resource for, either, retrieving or updating information about an identity, or performing some action for the benefit of said identity, is known as “identity service”. In this terminology context, a DS server provides a “discovery service” DS which allows a plurality of WSCs to dynamically discover the registered identity services of a user, so as to provide them with information usable to access to the corresponding WSPs.
A DS server is thus a functional entity that acts as a register to store information about the identity services of some users, and that provides said information upon request. The information that stores a DS server for each registered identity service of a given user is commonly known as “resource offering” RO, and its content is usable to uniquely identify a given identity service instance of a user. For example, for providing access to a “calendar” service of a user that stores his appointments and tasks, the DS server stores a RO that, among other, can comprise: an identifier of the service type to differentiate different kind of services (Service Type), an identifier which identifies uniquely a service instance of said service type which relates to said user (e.g to differentiate from the “calendar” of other user) (Resource ID), and an identifier which identifies the SP hosting said service for said user (Provider ID). All of these identifiers may have the form of Uniform Resource Identifiers URIs, although other representation formats (for example a single URI) are also possible as long as they provide a reference usable to contact with the corresponding SP so as to identify and access a given identity service of a given user.
To provide a discovery service DS, a state-of-the-art DS server is arranged to receive and answer two kind of requests: a first kind of request asking to modify a “resource offering” RO (either to insert a new RO, or to remove an stored RO), hereinafter referred as “Discovery Service update” DS-update; and a second kind of request requesting to obtain an stored RO, hereinafter referred as “Discovery Service query” DS-query, which answered by the DS server with a “Discovery Service response” DS-response comprising the corresponding RO(s).
Due to its own nature, the “discovery service” DS is itself an identity service that provides a consumption (in the form of discovery) of a special set of “resources” (i.e. Resource Offerings, ROs). A specification describing a Discovery Service in an identity web-services framework has been released by LAP as “Liberty ID-WSF Discovery Service Specification” version 1.1 (available in https://www.projectliberty.org/specs/liberty-idwsf-disco-svc-v1.1.pdf).
A brief example of this kind of new services, as well as a brief explanation about the functional relationships among the entities in an identity federation framework, shall now be given with references to FIGS. 1 and 2.
A plurality of SPs (110,120,130,140), a IDP (90), a DS server (100) and a human user (150-2) interacting with a user terminal (150-1) are schematically shown in FIG. 1. It is to be noticed here that, in LAP specific terminology, the generic term “principal” is used to refer to an entity that can acquire a federated identity; wherein the scope of the term “principal” can embody: human users, groups of human users, corporations, legal entities, or even functional serving entities. Since all those types of “principals” are actually “users” of the identity federation (or can become so), the term “user” (150) shall hereinafter be used in this application to refer indistinctly to a user of the identity federation regardless his/its type. The SPs of FIG. 1 (110,120,130,140) could represent each one or more server entities that can belong to the domain of one or more service provider organization; wherein each server entity may be co-located within the same server machine, such as a computer-based machine, or be distributed across various machines. Similarly, the corresponding functionality disclosed for the IDP or for the DS server could also be distributed across more than one machine (e.g. each performing a sub-function of the total functionality), or be co-located within the same machine. However, for the sake of simplicity, each of the server entities represented (90,100,110,120,130,140) can be assumed to represent a single machine, each implementing the corresponding disclosed functionality; although it shall be noticed that, in common practical implementations, the functionality of the IDP and the functionality of the Discovery Service use to be co-located within the same server machine.
For simplicity, only one DS server has been represented in FIG. 1; however, more than one DS server may exist within a telecommunications system which provides an identity federation framework; wherein, for example, each DS server is assigned to serve a Discovery Service to a set of users of said federation.
The user (150) can communicate (11) with more than one SP (110,120,130) and, as cited earlier, gain access to different services that are subject to user authentication by using SSO feature. SPs and IDP can also communicate (10) for authenticating users and for the delivery of, among other, authentication assertions. For example, the user (150) establishes a first communication with SP 110 and gets authenticated in this SP. The IDP (90) is involved in this authentication and, when the user establish a further communication with e.g. SP 120, the IDP provides an authentication assertion to SP 120, which grants access to the corresponding service in this SP without the user having to provide his credentials again.
As a part of the data exchanged between an IDP and SPs during the SSO authentication process of a user, the IDP can further provide to any SP contacted by the user (110,120,130) a reference usable to contact with the DS server (100) so as to obtain RO(s) of said user from said DS server (if needed). Said reference usable to contact with the DS is also considered as a “resource offering” itself (referred as RO-DS hereinafter), since it is used to access to an identity service, which, as cited earlier, is provided by the DS server (i.e. the “discovery service” DS). Further communications (12) can be established between SPs to access to identity services of the user (150).
The signaling flow shown in FIG. 2 shall now be used to explain how a RO for a given identity service of a user is stored in the DS server, and how it is further accessed. In a first step (flow 201), the user (150) access to a given SP (130) and decides to subscribe a given service offered by this SP. For example, SP 130 (e.g. a trade bank) offers a secure payment service via web; or, for example, SP 130 offers a calendar service which can be checked by the user via a web browser application from a personal computer or mobile phone, and which can also be checked (or updated) to provide other services (or as a result of other services). The access of the user to the SP, so as to request the subscription to a given service, may begin by sending an HTTP message (typically a HTTP “Get”) to a registration URL (Uniform Resource Locator) which is known by the user, or which is indicated by the SP on a web page. In the next step shown (flow 202), SP 130 sends a “discovery service update” DS-update to the DS server 100 that contains the corresponding RO for accessing said identity service for said user in said SP 130. The use of said RO may allow another SP (110), for example, to obtain a payment assertion for goods that are acquired by said user, or to check or update the user's calendar data.
As a result of a received DS-update, the DS server stores (203) the received RO. As shown schematically in FIG. 1, the DS server has a data storage (103-1) to store the plurality of ROs (RO1A,RO1B,RO2A,ROnB) for each of the users (USR-1,USR-2 . . . , USR-n) it serves a discovery service, and for each of the identity services that have been registered for each of said users.
Later, user 150 accesses SP 110 (flow 204), which, for example, offers a flight booking service accepting payments via web, and that further offers, e.g. as an extra feature, the checking and/or updating of the user's calendar (e.g. verifying user's availability marking the flying time as “unavailable”, setting a task to pick the ticket, etc.). Given that user (150) has been previously authenticated with the intervention of the IDP (90) (signaling flows not shown in FIG. 2), the SP 110 has obtained from the IDP a reference usable to contact with the DS (a RO itself, RO-DS, as mentioned above). Then, for example, to check or update the user's calendar, or to obtain a payment assertion for a booked flight, SP 110 sends a “discovery service query” DS-query (flow 205) to the DS server (100). The DS-query (205) comprises the resource identifier (Resource ID) of the RO obtained to access to the DS server (RO-DS), which allows the DS server to identify the particular user (150) involved, and can also comprise an identifier of the requested identity service (e.g. a Service Type identifier established for identifying the “calendar” service).
If a received DS-query comprises an identifier of a particular identity service (Service Type), the DS server (100) checks whether there is a RO registered for said service and said user. If the DS-query is received without an identifier of an identity service type, the DS server would answer back with a “discovery service response” DS-response (flow 206) with all the ROs stored for the referenced user. For example (with reference to the content of storage 103-1 in FIG. 1), in case of USR-1, it would answer back with a DS-response comprising RO1A and RO1B, or, in case of USR-2, with RO2A). Otherwise, if a received DS-query comprises an identifier of a particular identity service, the DS server would answer back with only the RO that corresponds to the indicated identity service (e.g. RO1B). Once obtained a DS-response (flow 206), SP 110 can use data of the obtained RO to invoke the identity service by communicating with the SP (130) which hosts the resource concerned by said identity service (flows 207,208) (thereby, e.g., accessing or updating the user calendar, obtaining a payment assertion, user profile data, etc).
However, when an identity service indicated in the DS-query is a non-registered identity service for said user (i.e. no RO is stored in the DS-server 100 for that identity service), or when there are no identity services at all registered for said user in the DS-server; the subsequent DS-response (206) is sent empty. Depending on the nature of the service which the SP 110 intends to provide to the user 150, this event can cause the final denial of said service, or, as a minimal consequence, an eventual reduction on the quality of the final service provided, which, for example, can require the user to manually indicate to SP 110 some of the needed data that, otherwise, would have been automatically obtained through the identity service if it was registered.
The user can overcome the aforementioned problem by contacting with a SP that can provide the identity service, so as to register for him the until now non-registered identity service. However, the user might have to contact with several SPs until he finally finds out one that can provide said identity service. Once found, the user could subscribe it, whereby flows 201 and 202 described above could run so as to register said identity service for said user in the DS server; and then, e.g., if he still wants to gain access to a service that was neglected, the user can go back and contact again with the SP (110) where the discovery of said identity service failed.
However, none of this can prevent that the same situation described above could be repeated for other identity services this user might later need which still remain as non-registered identity services for him. Moreover, new services can be quickly developed and implemented by SPs, which can involve the eventual provision and requests of new identity services. However, the state-of-the-art mechanisms for the registration of identity services (as described with reference to flows 201 and 202) prevents a quick deployment of said new services, since a user will still be forced to find the appropriate SPs and contact with them (201) so as to achieve said SPs to make the corresponding registrations (202) of the wanted identity services for him into a DS server.